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(54) System and method to specify extended configuration descriptor information in USB 
devices 



(57) The following system and procedure for speci- 
fying an extended configuration descriptor includes a 
USB device that responds to device requests from a 
host. In response to receiving a host-specific device re- 
quest that specifies a predetermined index, the USB de- 
vice returns an extended configuration descriptor to the 



requestor The extended configuration descriptor in- 
cludes information that can be used by the requestor to 
control the USB device. When the USB device Is a com* 
posite device: the extended configuration descriptor in- 
cludes function information corresponding to a plurality 
of sub-devices. Each function comprises one or more 
interfaces. 
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Description 

RELATED APPLICATIONS 

3 [0001] This appilcation is related to a prior US Patent Application fiied February 4, 2000, titled "Host-Specified USB 
Device Requests", serial number 09/498,056, which is hereby incorporated by reference. 

TECHNICAL FIELD 

10 [0002] The following description relates generally to the use of peripheral devices with software applications. More 
specifically, the following description relates to the use of device specific infonmation and resources with such software 
applications. 

BACKGROUND OF THE INVENTION 

15 

[0003] The Universal Serial Bus (USB) is a cable bus that supports data exchange between a host computer and a 
wide range of simultaneously accessible peripheral devices. The anached peripheral devices share USB bandwidth 
through a host-scheduled, token-based protocol. The bus allows peripherals to be attached, configured, used, and 
dciached while the host and other peripherals are in operation. 
20 [0004] The USB is defined by a specification that is approved by a committee of industry representatives. The spec- 
rfication covers all aspects of USB operation, including electrical, mechanical, and communications characteristics. To 
be called a USB device, a peripheral must conform to this very exacting specification. 

[0005] USB device information is typically stored in so-called "descriptors" or request codes — data structures for- 
matted as specified by the USB specification. Descriptors are used in a USB system to define "device requests" from 
^5 a host to a peripheral device. A device request is a data structure that is conveyed in a "control transfer" from the host 
to the peripheral device. A control transfer contains the following fields: 

• bmRequestType — a mask field indicating (a) the direction of data transfer in a subsequent phase of the control 
transfer; (b) a request type (standard, class, vendor or reserved); and (c) a recipient (device, interface, endpoint, 

30 or other). The primary types of requests specified in the "request type" field are the "standard" and "vendor" types, 

which will be discussed below. 

• bRequest — a request code indicating one of a plurality of different commands to which the devbe is responsive. 

• wValue^a field that varies according to the request specified by bRequest 

• wIndex—B field that varies according to request; typically used to pass an Index or offset as part of the specified 
35 request. 

• wLength^number of bytes to transfer if there is a subsequent data stage. 

[0006] All USB devices are supposed to support and respond to "standard" requests — referred to herein as "USB- 
specific". requests. In USB-specif ic requests, the request type portion of the bmRequestTypei\e\6 contains a predefined 

40 value indicative of the "standard" request type. 

[0007] Each different USB-specific request has a pre-assigned USB-specific request code, defined in the USB spec- 
ification. This is the value used in the bRequest field of the device request, to differentiate between different USB- 
specific requests. For each USB-specific request code, the USB specification sets forth the meanings of wVaiue and 
windex, as well as the fonnat of any returned data. 

45 [0008] USB devices can optionally suppon *Vendor" requests — referred to herein as "device-specific" requests. In 
a device-specific request, the request type portion of the bmRequestTypei\e\6 contains a predefined value to indicate 
a "vendor" request type. In the case of device-specific requests, the USB specification does not assign request codes, 
define the meanings of wValue and windex, or define the format of returned data. Rather, each devce has neariy 
complete control over the meaning, functionality, and data forrnat of device-specific requests. Specifically, the device 

so can define its own requests and assign device-specified request codes to them. This allows devices to implement their 
own device requests for use by host computers, and provides tremendous flexibility for manufacturers of peripherals. 
[0009] The inventors have discovered a need for a simitar feature that would benefit various hosts, application pro- 
grams, host operating systems hardware manufacturers (OEMs), and Independent Hardware Vendors (IHVs). Specif- 
ically, designers of application programs and operating systems would value the opportunity to define their own device 

55 requests (and the associated responses), and to have such requests supported in a unifomi way by compatible pe- 
ripherals. Moreover. OEMs and IHVs would value the ability to supply additional USB device specific infonnation to 
the hosts, application programs and host operating systems in response to such device requests. However, the different 
request types supported in the bmRequestType field of a USB device request do not include a "host** type of request. 
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[0010] As an example of this need for a host type of request, consider that the USB Device Working Group (DWG) 
has defined a set of standards that describe different types of USB devices. For each of these standards, the DWG 
has created a respective class, specification that specifies static predetermined class and subclass numbers that cor- 
respond to the class specification. These specifications are designed such that to be in compliance with a particular 
5 class specification, an operating system must Include only a single default, or "generic" device driver to control a USB 
device that is configured according to the particular class specification. 

[001 1 ] When a USB device is installed onto a system, the device indicates that it was created according to a particular 
DWG class specification by listing predefined class and subclass codes that correspond to the DWG specification. 
These predefined codes can be used by an operating system to load a single generic device driver to control the device. 

10 [0012] However It is often the case that a vendor of a USB device would prefer that a different, or "more specific" 
device driver be used to control the device, rather than the generic device driver supplied by the operating system. For 
example, a more specific device driver may be preferred to work around known bugs in the device's software, provide 
product identification, use value added features, and the like. Such more specific device drivers are typically supplied 
by OEM/IHV supplied installation media that are distributed with a device. Such installation media include installation 

15 disks (e.g., floppy diskettes) or setup computer program applications. 

[0013] To provide for more specific device driver matches with respect to a USB device, USB device descriptors 
include markings that describe the manufacturer, product, and revision. An operating system (OS) can use such mark- 
ings to determine whether a more specific, and therefore a more customized device driver match is available from the 
inslallalion media. If for some reason a specific match is not found, the. concepts of class and subclass codes, as 

20 described above, facilitate the loading of a generic devtee driver to control the device. 

[0014] One of the benefits of using a USB device is the reduced amount of interaction typically required of a user to 
attach and configure a device. This has been a strong point of USB and has lead to increasing sales of USB devices 
over the past few years. Thus, being able to load a device driver without having to use additional OEM/IHV supplied 
installation media to configure the device greatly simplifies end user USB device attachment scenarios. 

25 [0015] Unfortunately, unless the USB DWG has already allocated certain class and subclass codes for a particular 
USB device, that particular devtee cannot have a match based on class and subclass codes to identify a generic device 
driver to control the device. If the device's corresponding class and subclass codes are not supported by the DWG, 
an OEM/IHV distributing the device must at least provide installation media with the device to specify a given match 
that corresponds to a generic driver that is already present on the system. Otherwise, the OEM/IHV must supply a 

30 special device driver with the con^esponding installation media, 

[0016] In light of the above, a user of a device that specifies non-standard DWG class codes is required to use suich 
installation media to load a device driver to control the device. It would be beneficial both in terms of simplifying matters 
for OEMs/lHVs and simplifying customer ease of use If an operating system could specify a default device driver that 
is already present on the system in response to installing a device that does not specify a standard USB DWG class 

35 and/or subclass code. 

[0017] Ideally, an operating system vendor could develop a new standard USB device class— one not supported by 
DWG.and distribute a devrce driver to control devices built to that new standard with the operating system. In this 
manner, an OEM/IHV could not only distribute devices built to that standard before the USB DWG has adopted a 
corresponding class and subclass code, but also distribute such devices without needing to supply a special device 
40 driver and con-esponding installation media. In this way the operating system would natively support the new non- 
standard USB device by providing a generic device driver to control the new device. 

[001 8] To natively support a non-standard USB device, an operating system would have to request specif k: informa- 
tion from the new device to identify the new device's non-standard class and subclass codeis to determine the particular 
generic device driver to control the new device. However, in response to device specific requests from an operating 
45 system, a USB device (as currently defined by the USB specifications) can only return infonnation related to vendor 
identification, product identification, and revision information. There is no standard request to allow a vendor to return 
additional information to an operating system to indicate thai the devtee supports non-standard class and/or subclass 
codes — those not supported by the USB DWG. 

[001 9] Thus, it would be beneficial if a USB device could indicate through a predefined USB request that it supports 
so such non-standard class and/or subclass codes. This information could be used by an operating system to install 
default device drivers to control the LJSB device. However, as discussed above, such a USB request is not defined by 
the USB specification. 

[0020] In yet another example that Illustrates the need for a host specific USB request, consider that the DWG has 
established a number of well-defiried requests to obtain interfaces that correspond to functions in certain composite 
55 devices. A composite device includes a number of logical devices (LDs), wherein each LD is a fully functional sub- 
device of the composite device. There is typically a one-to-one con-espondence between a function and an interface 
in a composite device, with the exception of certain devices such as USB speaker devk:es, which implement more 
than one interface for a single function. In such exceptional cases, because the DWG has a predefined request to 
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return the multiple interfaces that correspond to a function, each interface can be returned in response to a single 
request. 

[0021] Othenvise, when the DWG has not defined such a request, a complex procedure must typically be imple- 
mented to determine each of the interfaces that correspond to respective functions in a composite device. For example. 

5 to determine if a USB device is a composite device, a host must first request the device to indicate how may functions, 
or LDs that it supports. In response, a composite device wilt indicates its ability to support multiple functions by first 
identifying the number of logical devices (LDs) that the device supports. Next, to obtain specific information corre- 
sponding to each supported LD, the host must typically issue separate requests, each request being overloaded with 
a respective LD identification^ to obtain each respective LD descriptor. Thus, a typical composite USB device would 

10 not return information corresponding to each interface grouping defined in the composite device in response to a single 
query unless the single query was already predefined by the DWG to return more than one interface in response to a 
. single request. 

[0022] It would be beneficial to USB composite device makers and to software developers if there was a simple way 
for a USB device to specify the interfaces that comprise a single function, such that the interfaces could be determined 
15 without the needing to implement the complex procedure discussed above. In this manner, newer composite devices 
not yet supported by the DWG could be treated exactly as the ones currently supported by the DWG. 
[0023] Accordingly, the invention arose out of concerns associated with providing a host-specific device request that 
solves the problems described above. 

20 SUMMARY 

[0024] One embodiment of the described system and procedure specifies non-standard compatible IDs, or non- 
standard class and subclass codes in a USB device in response to a host-specific device request. A non-standard 
compatible ID is a class or subclass code that is not supported or defined by the USB DWG. The USB device comprises 

25 an extended configuration descriptor in firmware of the USB device. The extended configuration descriptor comprises 
a set of non-standard class codes that can be used by a host operating systenni to identify one or more device drivers 
to control the device. Responsive to receiving a host-specific device request from the operating system, the USB device 
communicates the extended configuration descriptor to a requestor. Thus, the system and procedure of this implemen- 
tation simplifies end-user device installation scenarios and allows OEMs/I HVs to Implement new USB devices without 

30 distributing special device drivers and/or corresponding installation media with each single new USB device. 

[0025] Moreover the extended configuration descriptor includes a header section and one or more control function 
sections. The header section indicates the number of control functions for which mappings exist in the extended con- 
figuration descriptor. Each control function section indicates information corresponding to a respective function for the 
USB device. Each control function comprises one or more interfaces. Because the extended configuration descriptor 

35 is communicated to a requestor responsive to the receipt of a single host-specific device request, the Inventive concepts 
of this implementation provjde a simple way for a new USB device to specify a group of interfaces that comprise a 
single function. 

BRIEF DESCRIPTION OF THE DRAWINGS 

40 

[0026] 

Fig. 1 is a block diagram of an exemplary host/peripheral USB system. 

Fig. 2 is a flowchart diagram that shows top-level methodological aspects of an exemplary procedure to obtain 
45 and use a device-specific request code for host-specific device requests. 

Fig. 3 is a flowchart diagram that shows detailed aspects of an exemplary procedure to obtain a device-specific 
request code. 

Fig. 4 is a block diagram showing aspects of an exemplary data structure for an extended configuration descriptor 

50 DETAILED DESCRIPTION 

[0027] The following description sets forth a specific embodiment of a system and procedure that incorporates ele- 
ments recited in the appended claims. The embodiment is described with specificity in order to meet statutory require- 
ments. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have 
55 contemplated that the claimed subject matter might also be embodied in other ways, to include different elements or 
combinations of elements similar to the ones described in this document, In conjunction with other present or future 
technologies. 
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Exemplary System 

[0028] Fig. 1 shows a system 100 wherein a USB device includes non-standard compatible IDs. or non-standard 
class and subclass codes. Additionally, the system includes a host application program and host operating system that 
5 is able to enumerate non-standard compatible IDs, or non-standard class and subclass code corresponding to USB 
devices. System 1 00 is compatible with the Universal Serial Bus (USB) specifications. These specifications are avail- 
able from USB Implementers Forum, which has current administrative headquarters in Portland, Oregon (current In- 
ternet URL: www.usb.org ). 

[0029J System 1 00 includes a host computer 1 02 and a USB peripheral device 114. The respective functionality of 
10 the computer and peripheral device is embodied in many cases by computer-executable instructions, such as program 
modules, that are executed by respective processors. Generally, program modules include routines, programs, objects, 
components, data structures, etc. that perform particular tasks or implement particular abstract data types. 
[0030] Computer 1 02 is a conventional desktop PC or other type of computer. Computer 1 02 has one or more proc- 
essors 104 and one or more forms of computer-readable memory media 106 such as electronic memory, magnetic 
15 storage media, optical storage media, or some other type of data storage. Programs are stored in memory 106 from 
where they are executed by processor 1 04. In this example, such programs include an operating system 108 such as 
the Microsoft "Windows'XB) family of operating systems. The operating system provides various system services to one 
or more application programs 110 running on the computer. 

[0031] The computer also has a USB communications driver and port 112, The USB port is supported by operating 
20 system 1 08. To communicate with a USB device, an application program 1 1 0 makes high-level calls to system services 
provided by the operating system. The system sen^ices take care of lower level communications details, and return 
requested information to the application program. 

[0032] Peripheral device 11 4 is one of any number of different types of USB devices such as a data storage device, 
a digital camera, a scanner, a joystick, game pad. steering unit, mouse, stylus, digital speaker, microphone, display 

25 device, and the like. Peripheral device 114 has one or more processors 116 and one or more fomns of computer- 
readable memory media 118, including at least some form of non-volatile memory media 1 20. 
[0033] The peripheral device 114 has a USB port 126 and communicates with computer 102 via a USB communi- 
cations medium 128. The peripheral device also has operating logic 124, which is executed byprocessor 116 to detect 
control actuation and for communicating with computer 102 across communication path 128. 

30 [0034] The peripheral device 114 responds to requests from the host computer 1 02 across the communication path 
128. These requests are made using control transfers where setup packets (not shown) are exchanged. The USB 
device returns descriptors in response to exchanging such setup packets. Although the USB Specification defines a 
number of different standard class and vendor specific descriptors, an extended configuration descriptor 122 is not 
defined in the USB specification. The extended configuration descriptor allows OEMs/IHVs to store non-standard class 

35 and subclass codes— those that are not yet defined by the USB DWG, into non-volatile memory 120 of the device. 
Moreover, the extended configuration descriptor provides a simple way for a composite USB device to specify a group 
of interfaces that comprise a single function. 

[0035] Extended configuration descriptor 1 22 provides non-standard class codes and sut)class codes on a per func- 
tion basis. (Device vendors can build multiple functions into a device). A function is an independently controlled aspect 
40 of a device. A function can be considered to be a group of interlaces conglomerated together that serve a similar 
purpose. Class codes are also referred to herein as "compatible ids'*. Subclass codes are also referred to herein as 
"sub-compatible Ids". 

[0036] Peripheral device 114 supports host-specific device requests to obtain infonmation that Is not specified in the 
USB specification. In this implementation, prior to using the peripheral device, the computer sends a host-specific 

45 request to the peripheral device requesting class codes and/or subclass codes that con-espond to the peripheral device. 
In response to the request, the peripheral device provides extended configuration descriptor 122 to the computer. 
Within the extended configuration descriptor, the computer locates data corresponding to the peripheral device 114, 
and extracts non-standard class and/or subclass codes, as well as one or more interfaces that correspond to one or 
more functions. The operating system then loads device drivers based on the extracted extended configuration de- 

50 scriptor to control and interface with the peripheral device. 

Exemplary Procedure to Obtain a Device SpecWic Request Code 

[0037] Fig. 2 shows top-level methodological aspects of an exemplary procedure to obtain a device-specific request 
55 code for a computer to use when making a host-specific device request. Generally, a new non-standard USB-specifk: 
device request is defined for use with various USB peripherals. This request is refered to herein as a host-specific 
device request. Because of the described methodology, the host-specific device request can be defined by the man- 
ufacturer of an operating system or application program, and can then be made available to peripheral vendors so that 
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they can support and respond to the newly defined request. As an exannple, an OS manufacturer nnrght define a new 
descriptor allowing peripherals to return device specific data and resources to an operating systenn in a data format 
that is determined by the operating system. This would allow the operating system to use a single device request to 
obtain this information from various different peripherals (assuming those peripherals are configured to support the 
5 new device request). 

[0038] In an initialization phase 200, the host sends a request to the peripheral In the fomn of a USB-specified device 
request. The request Is for a device-specific request code — of the device's choosing— that will be subsequently used 
as the request code for the host-specific device request. 

[0039] Once this request code is obtained, it is used in a subsequent phase 202 to initiate the host-specified device 
10 request to obtain the extended configuration descriptor 122 (see Fig. 1). Specifically, the host specifies the request 
code as the bRequest value In a control transfer (see the "Background" section for details regarding a control transfer). 
The actual protocol of this device request (meanings of bindex, bVaiue, etc.) is as specified in the definition of the host- 
specific device request. Phase 202 Is repeated as desired during subsequent operation, without repetition of initiali- 
zation phase 100. 

75 [0040] Fig. 3 shows more details regarding the initialization phase 200. The host pertonns an action 300 of sending 
a GET_DESCRIPTOR device request to the peripheral device. The GET^DESCRIPTOR deyice request is a standard, 
USB-speclfic request, Identified in a control transfer by the GET_DESCRIPTOR request code {bRequest = 
GET_DESCRIPTOR). The fields of the control transfer (discussed above In the baclcground section) have values as 
follows: 

20 

• bmRequestType = 10000000 (binary), indicating a "device-to-hosr transfer, a "standard'" or "USB-speclfic" type 
request, and a device recipient. 

• bRequest = GET_DESCRIPTOR This is a constant (six) defined by the USB specification 

• wValuc = 03EE (hex). The high byte (03) indicates that the request Is for a "string" descriptor, and the low byte is 
25 an index value that is predefined as a constant in the definition of the host-specified device request. In this example, 

it has been defined as EE (hex), but could be predefined as any other value. 

• wfndex = 0. 

• wLength = 12 (hex). This is the length of a host-specific request descriptor that will be returned In response to this 

request. In the described example, the length is 12 (hex). 
30 • data — returned host-specific request descriptor. 

[0041] A compatible USB device is configured to respond to a request such as this (where wValue = 03EE (hex)) by 
returning a host-specific request descriptor such as the extended configuration descriptor 122 of Fig. 1 . This descriptor 
is not defined by the USB standard, but has fields as defined in the following discussion. The host-specific request 
35 descriptor designates a device-specific request code that will woric on this device to initiate the host-specific request 
code. In other words, the manufacturer of the device can select any device-specific request code, and associate it with 
an implementation of the host-specific device request. 

[0042] More specifically, the device receives the GET_DESCRIPTOR device request (block 302) and performs a 
decision 304 regarding whether the index value (the second byte of wVaiue) corresponds to the predetemiined value 
40 (EE (hex)). This predetermined value Is a value that is chosen to be used specifically for this purpose. 

[0043] If the index value does not con-espond to the predetermined value, the device responds at 305 in an appro- 
priate way, usually by returning some other descriptor that corresponds to the index value. If the Index value does 
correspond to the predetenmined value, an action 306 is perlomned of returning the host-specific request descriptor to 
the host. 

45 [0044] The host-specific request descriptor includes, for example, the following fields: 

• /7/.enp//>^the length of the descriptor (12 (hex) in this example). 

• bDescriptorType — the type of descriptor (string type in this example). 

• qwSignature—a signature confimning that this descriptor is indeed a descriptor of the type requested. The signature 
so optionally incorporates a version number. For example, in the described example MSFT100 indicates that this 

descriptor is for an "MSFT* host-specific device request, version "1 00" or 1 .00. 

• bVendorCode— the device-specific request code that |s to be associated with the host-specified device request. 

• bPad—a pad field of one byte. 

55 [0045] At 308, the host receives the host-specific request descriptor and then performs an action 310 of checking 

or verifying the signature, and version number found in the qwSignature field. The correct signature confirms that the 
device is configured to support host-specific request codes. If either the signature or version number is incorrect, at 
311 the host assumes that the device does not support host-specific request codes, and no further attempts are made 
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to use this feature. 

[0046] The signature field of the host-specific request descriptor block is what provides backward compatibility. A 
non-compatible device (one that doesn't support host-specific request codes) nnight use the predetemnined wValue 
03EE (hex) to store some other string descriptor, which will be returned to the host without any indication of problems. 
5 However, this will become apparent to the host after it examines the data in the location where the signature is supposed 
to be. If the signature is not found, the host knows that the retumed descriptor is not of the type requested, and will 
assume that the device does not support host-specific request codes. 

[0047] If the signature and version are conf imned in block 3 1 0, at block 31 2 the host reads the device-specific req uest 
code from the bVendorCodei\e\6, and uses it in the future as a host-specific request code, to Initiate the host-specific 
10 device request. When using the device, the host sends the host-specific device request by specifying the obtained 
device-specific request code as part of a control transfer. The device responds by perfomiing one or more predefined 
actions or functions that correspond to the host-specific device request, in accordance with the specification of the 
host-specific device request. 

[0048] The host-specific device request itself is in the fomiat of a normal USB control transfer. Including the fields 
IS discussed in the "Background" section above. The bHequest field is set to the value of the bVendorCode field of the 
host-specific request descriptor, which was earlier obtained from the peripheral device. The bmRequestType field is 
set to 11000001 (binary), indicating a device-to-host data transfer, a "vendor or devtee-speclfic request type, and a 
device recipient. 

[0049] The wValue and windex fields are used as defined by the definition of the host-specific device request. The 
20 ivLenpr/) field indicates the number of bytes to transfer if there is a subsequent data transfer phase in the device request. 
[0050] In a presently prefen-ed implementation of this system, the host-specific device request is used to request 
one of a plurality of available host-defined string descriptors from the devtoe. The iv/nde»f field of the host-specific 
device request indicates whteh of the plurality of strings are to be returned. The device returns the descriptor referred 
to by windox. 

25 [0051] The techniques described above allow an operating system designer to specify informational descriptors that 
devices can Implement to provide additional data about themselves— data that is not directly addressed by the USB 
specification. For example, the techniques described above allow an operating system to specify the extended con- 
figuration descriptor 122 of Fig. 1 . The operating system uses the extended configuration descriptor to enumerate all 
USB devices that support non-standard USB DWG class codes and/or subclass codes to determine one or more device 

30 drivers to control the devices. The extended configuration descriptor and procedures to use the extended configuration 
descriptor to enumerate non-standard compatible ids are described in greater detail below in reference to Fig. 4 and 
Tables 1-2. 

Exemplary Data Structures 

35 

[0052] Fig. 4 shows elements of an exemplary data structure for the extended configuration descriptor 122, which 
is an example of the host-specific request descriptor described above. The extended configuration descriptor 122 
includes a header section 400 and a function section 402. The header section includes a number of elements 404 that 
describe the function section. The function section includes one or more control functions 406. Each instance of a 
40 control function 406 encapsulates infonnation corresponding to a single function for the peripheral device 114. 

[0053] Header section 400 stores information about the remaining portions of the extended configuration descriptor 
1 22. Header section 400 includes the following fields: 

• dwlengtb^Xhe total length of the extended configuration descriptor; 

43 • bcdVersion — the version number of the extended configuration descriptor; 

• windex — identifies the extended configuration descriptor; and 

• wCoun^Khe total number of control function sections 406 in the function section 402. 

Using this information, the operating system or application program can parse the following function section. 
so [0054] Function section 402 is of variable size because it includes one or more control function sections 406. Each 
control function section includes information that corresponds to a single function for the peripheral device. The function 
section includes the following fields: 

• d*vS/ze— the total length of this control function section; 

55 • qwCompatiblelD-^Xhe compatible ID, or class code for this function; 

• qwSubCompatibleiD— the sub-compatible ID, or subclass code for this function; 

• /)rofa//n/ertaces— the number of interfaces grouped together to generate this function; 

• /7/nfe/aceA/L//ntef— the interface number 
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[0055] The qwCompatiblelD and qwSubCompatiblelD values are used to override any USB DWG standard compat- 
ible ids and/or sub-compatible ids that nnay be defined for the device. This means that if USB DWG standard class 
and/or subclass codes are defined for the USB device, that these standard codes will be ignored in view of the extended 
configuration descriptor provided compatible and/or sub-compatible ids. The qwCompatiblelD and qwSubCompati- 
5 btelD values should not be confused with the USB DWG defined class and subclass codes — regardless of whether 
they are used in the extended configuration descriptor. 

[0056] The bTotallnterfaces field Is a value that represents the total number of interfaces that have been grouped 
together for this particular function. Each individual interface number (btnteraceNumbei) forming the function is rep- 
resented below it. 

10 

Example Extended Configuration Descriptor Use 

[0057] For an operating system to use an extended configuration descriptor stored on a device, the device must first 
provide information to the operating system that indicates that the device supports host-specific device requests. In 
15 this implementation, this is accomplished by storing the string descriptor shown in TABLE 1 at index OxEE on the USB 
device. The string descriptor defines an operating system descriptor that is returned to the operating system in response 
to a USB device request as discussed above. In this Implementation, the string descriptor index is OxEE, however it 
could be stored at some other location In the USB device. 

20 

TABLE 1 

Example of an Operating System String Descriptor 

25 const byte os_descriptorO=={ 

0x12, //length 

0x03, . //string descriptor type 

JA^^S^JF^jr^J^J^Ji^ //data 
30 0x01, //index 

0x00 //reserved 

>• 

.35 ' V *• 

[0058] Next, the extended configuration descriptor is stored in a format specified by the operating system on the 
firmware of the USB device. The extended configuration descriptor is shown below in TABLE 2 In this imjalementation, 
the USB device is a device that is compatible with a Remote Network Device Interface Specification (RNDIS) that is 
not supported by the USB DWG. (This means that the USB DWG has not supplied any compatible ids for RNDIS 
40 devices). In this implementation, the device needs to Indicate to the operating system that It Is compatible with the 
RNDIS. To accomplish this, the device Implements the following extended configuration descriptor. 
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TABLE 2 

Example of an Extended Configuration Descriptor for a RNDIS 
Compatible USB Device 

const byte mem_stick_descriptor|]={ //header section 

// dwLength (DWORD) 
//bcdVersion 
//windex 
//wCoimt 

// function section 
//wSize 

// qwCompatiblelD 
// qwSubCompatiblelD 
// bTotallnterfaces 
//First Interface in function 1 
// Second interface in function = 3 



[0059] When the RNDIS compatible device is attached to the USB port on the computer, the operating system re- 
trieves the extended configuration descriptor from the device by using the following API call: 

GET DESCRIPTORC 

bmRequestType = 1 100 OOOIB, // device-to-host data transfer 

bRequest = 0x01, // this request 

wValue - 0x0000, // string descriptor indication 

windex = 0x0004); //this index 

40 [0060] In response to receiving this request, the USB device returns the extended configuration descriptor to the 
operating system. Upon receiving the extended configuration descriptor, the operating system detemnines the non- 
standard compatible ids based on the extended configuration descriptor. The operating system uses the non-standard 
compatible ids to load generic (or default) device drivers to control the USB device. This is beneficial because OEMs/ 
IHVs who develop USB devices that are not fully supported by USB DWG standard class and subclass device drivers 

45 can specify non-standard class and subclass device drivers to control the USB devices. 

[0061] Moreover, unless the DWG has a predefined request that returns one or more multiple interfaces that corre- 
spond to a function in a composite USB device, a complex procedure must typically be implemented in traditional 
systems and procedures to determine the interfaces that correspond to the functions. However, the extended config- 
uration descriptor of this implementation includes each interface to function mapping implemented by a composite 

so device. Thus, in contrast to such traditional systems and procedures, this implementation provides a simple way for a 
new composite USB device to specify a group of interfaces because the extended configuration descriptor is commu- 
nicated to a requestor in response to receipt of a single host-specific device request. 

[0062] Although the invention has been described in language specific to structural features and/or methodological 
steps, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific 
55 features or steps described. Rather, the specific features and steps are disclosed as preferred f onus of implementing 
the claimed invention. 
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Claims 

I. A method comprising: 

5 providing an extended configuration descriptor in fimiware of a USB device, the extended configuration, de- 

scriptor coinprising a set of non-standard class codes ; and 

responsive to receiving a host-specific device request, communicating the extended configuration descriptor 
to a requestor. 

10 2. A method as recited in claim 1 , wherein the set of non-standard class codes includes non-standard subclass codes. 

3. A method as recited in claim 1 , wherein a non-standard class code comprises a class code or a subclass code 
that is not defined by the USB DWG. 

15 4. A method as recited in claim 1 , wherein the extended configuration descriptor further comprises: 

a control function section Indicating information corresponding to a function for the USB device. 

5. A method as recited in claim 1 , wherein (he extended configuration descriptor further comprises: 

20 

a header section indicating the number of control function sections for which mappings exist in the extended 
configuration descriptor; and, 

one or more control function sections, each control function section indicating Information corresponding to a 
single function for the USB device. 

25 

6. One or more computer-readable media containing a computer executable program that performs a method as 
recited in claim 1 . 

7. A method comprising: 

30 

querying a USB device using a host-specific device request to obtain a descriptor indicating a set of non- 
standard class codes: 

determining one or more compatible device drivers based on the set of codes indicated by the descriptor: and 
loading the one or more compatible device drivers to control the USB device. 

35 

8. A method as recited in claim 7. wherein the querying comprises: 

communicating a standard USB request to the USB device; and 

returning the extended configuration descriptor in response to the standard USB request, the extended con- 
40 figuration descriptor corresponding in the USB device to a host specific device request. 

9. A method as recited in claim 7, wherein the set of non-standard class codes includes non-standard subclass codes. 

10. A method as recited in claim 7, wherein a non-standard class code comprises a class code or a subclass code 
45 that is not defined by the USB DWG. 

II. A method as recited in claim 7, wherein the extended configuralion descriptor comprises: 

a control function section indicating information corresponding to a function for the USB device. 

so 

12. A method as recited in claim 7. wherein the extended configuration descriptor comprises: 

a header section indicating the number of control function sections for which mappings exist in the extended 
configuration descriptor; and, 

55 one or more control function sections, each control function section indicating infomnation con-esponding to a 

single function for the USB device. 

13. One or more computer-readable media containing a computer executable program that perfonns a method as 
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recited in claim 7. 



14 In a USB device that responds to device requests fronn a host, the device requests including USB-specific device 
requests with corresponding USB-specifted request codes and device-specific device requests virith corresponding 
5 device-speciJied request codes, the USB-specific device requests including a GET^DESCRIPTOR device request 

with a corresponding GET_DESCRIPTOR request code, a method of implementing a host-speciftc device request 
to determine one or more device drivers to control the USB device, the method comprising: 

receiving a GET_DESCRIPTOR device request that specifies a predetenmined index; 
10 responding to the GET_DESCR1PT0R device request by returning an extended configuration descriptor that 

corresponds in the USB device to the host-specific device request for a device-specific request code, the 
extended configuration descriptor specifying a non-standard class code that identifies a device driver to control 
the USB device. 

15 15, A method as recited in claim 14, wherein the extended configuration descriptor comprises: 

a control function section indicating information corresponding to a function for the USB device. 

16. A method as recited In claim 14. wherein the extended configuration descriptor comprises device specilic infer- 
20 mation. the device specific information comprising: 

a header section indicating the number of control functions for which mappings exist in the extended config- 
uration descriptor: and, . , . ^. * 
one or more control function sections, each control function section indicating information conrcsponding to a 

25 single function for the USB device. 

17. One or more computer-readable media containing a computer executable program that performs a method as 
recited in claim 14. 

30 18. A computer-readable medium containing computer-executable instructions utilized by an application program to 
interact with a USB control device, the computer-executable instructions conrprlsing: 

receiving a request from an application program for a set of non-standard class codes and subclass codes 
that correspond to the USB control device; . 
35 querying the USB control device to obtain an extended configuration descriptor, the extended configuration 

descriptor corresponding to a host-specific device request that identifies the set of non-standard class codes 
and subclass codes; and 

returning the obtained extended configuration descriptor to the requesting application program. 
40 1 9. A computer-readable storage medium as recited in claim 1 8, further comprising: 

determining, by the requesting application program, one or more default device drivers based on the returned 
extended configuration descriptor; and 

loading the one or more default device drivers to control the control device. 

20. A computer-readable storage medium as recited in claim 1 8, wherein the obtained extended configuration descrip- 
tor comprises: 

a control function section indicat.ng infonmalion corresponding to a function for the USB device. 

21 . A computer-readable storage medium as recited in clainri 1 8. wherein the obtained extended configuration descrip- 
tor comprises: 

a header section indicating the number of control functions for which mappings exist in the extended config- 

55 uration descriptor; and, 

one or more control function sections, each control function section indicating information corespondmg to a 

single function for the USB device. 
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22. A computer comprising one or more computer-readable media as recited in claim 18. 

23. One or more computer-readable media containing a computer-executable program for use in conjunction with a 
USB device that responds to device requests from the program, the device requests including USB-specific device 

5 requests with corresponding USB-specified request codes and device-specific device requests with corresponding 

device-specified request codes. , the program comprising: 

sending a request to the USB device for an extended configuration descriptor indicating one or more control 
functions that correspond to the USB device; 
10 receiving the extended configuration descriptor from the USB device in response to the request, wherein the 

extended configuration descriptor corresponds in the USB device to a host-specific device request. 

24. One or more computer-readable media as recited in claim 23. wherein the extended configuration descriptor com- 
prises: 

15 

a control function section indicating information corresponding to a function for the USB device. 

25. One or more computer-readable media as recited in claim 23. wherein the extended configuration descriptor com- 
prises: 

20 

a header section indicating the number of control functions for which mappings exist in the extended config- 
uration descriptor; and, 

one or more control function sections, each control function section indicating information corresponding to a 
single function for the USB device. 

25 

26. One or more computer-readable media as recited in claim 23, wherein the program further comprises: 

determining one or more compatible device drivers based on the received extended configuration descriptor. 
30 27. A computer comprising one or more computer-readable media as recited in claim 23. 

28. A USB device comprising: 

a processor; 
35 a port coupled to the processor; 

a memory coupled to the processor; 

an extended configuration descriptor stored in the memory, the extended configuration descriptor comprising 
infomiation that identifies a set of non-standard compatible IDs conresponding to the USB device; and 
a control program module stored in the memory, the control program module being configured to send the 
40 extended configuration descriptor to a requestor responsive to receiving a host-specific device request at the 

port. 

29. A USB device as recited in claim 28, wherein the set non-standard compatible IDs comprise class codes and/or 
subclass codes that are not defined by the USB DWG. 

45 

30. A USB device as recited in claim 28, wherein the extended configuration descriptor comprises: 

a control function section indicating information corresponding to a function for the USB device. 

50 31. A USB device as recited in claim 28, wherein the extended configuration descriptor comprises: 

a header section indicating the number of control functions for which mappings exist in the extended config- 
uration descriptor; and, 

one or more control function sections, each control function section indicating information corresponding to a 
55 single f u notion for the USB device. 

32. A USB device as recited in claim 28, wherein the USB device further comprises: 
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R plurality of logical devices, each logical device (LD) being a sub-device of the USB device: 

wherein the extended configuration descriptor further comprises a set of inforrnation corresponding to a 
plurality of interfaces, each LD corresponding to one or more of the interfaces: and 
5 wherein the control program module is further configured to communicate the set of information to a requestor 

responsive to receiving a single request at the port,. 

33. A USB device as recited in claim 28, wherein the set of non-standard compatible IDs are not supported by the DWG. 

10 34. A USB device as recited In claim 28, wherein the extended configuration descriptor further comprises: 

a control function section indicating information corresponding to a function for the USB device. 

35. A USB device recited in claim 28, wherein the extended, configuration descriptor further comprises: 

a header section indicating the number of control functions for which mappings exist in the extended config- 
uration descriptor; and, 

one or more control function sections, each control function section indicating information corespondlng to a 
single function for the USB device. 
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36. A computer-readable medium having stored thereon a data structure, comprising: 

a f irat data field comprising data indicating a count indicating the number of USB control functions for which 
mappings exist in a descriptor; and 
2s one or more second data fields, the number of second data fields based on the count, each second data field 

comprising data corresponding to a single function for a USB device. 

37. A computer-readable medium as recited in claim 36, wherein the first data field further comprises: 

30 a total descriptor length indication: and 

a descriptor version indication. 

38. A computer-readable medium as recited in claim 36, wherein each second data field further comprises a class 
code to override a standard USB DWG standard class code. 

35 

39. A computer-readable medium as recited in claim 38, wherein the class code is selected from a group of identifi- 
cations comprising a compatible class code and a sub-compatible class code. 

40. A computer-readable medium as recited in claim 36, wherein each second data field further comprises: 
a control function length indication; 

a total number of interfaces indication, the total number of interfaces being grouped together to generate a 
control function; and 
an interface number 
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